服務協作（Service Orchestration）模式將服務執行的順序、邏輯判斷以及錯誤時的例外處理統一由協作器(Orchestrator)進行指揮。因為業務邏輯的集中，所有溝通的發生都是由協作器呼叫參與的服務，而參與的服務並不會主動地協作器產生關係，也不會了解到其它服務的存在，這使得服務間的依賴關係更加地單純。
同時，微服務在複雜業務下的執行順序、處理邏輯將被統一地撰寫。透過實作出服務協作模式，開發者在通盤了解某個業務的全貌將簡單快速。在複雜的業務場景時，服務協作模式相比其他模式來說可能會因為頻繁的溝通而造成效能損耗。但因其將執行邏輯整合在單一協作器且直觀的特性，會更適合傳達概念以及維護。
而在服務協作模式中，協作器扮演的角色不僅僅是流程控制，它還需要負責資源的管理以及協同各服務的認證和授權，甚至是提供統一的日誌和監控機制等等。當業務流程變更或有新的需求出現時，只需要調整協作器的邏輯，不必修改每一個微服務，這極大地提高了系統的靈活性和擴充性。
然而，這也帶來了一定的挑戰。
首先，協作器可能會成為瓶頸，因為所有的服務呼叫都要先通過它才能流向相應的微服務。因此協作器將成為整體系統的流量集中處，也因為如此若協作器出現問題，可能導致整體系統的故障。為了解決這個問題，通常需要建立起協作器伺服器集群以確保高可用性。
其次，隨著業務複雜性增加，協作器的邏輯也會相應變得複雜，可能增加了出錯的機率。根本地來說，將邏輯集中在單一協作器是一種耦合的行為，雖然並不是所有的耦合都是壞事，但此種耦合可能會造成開發者過於依賴協作器集中的特性，讓某些本來應該由微服務本身處理的邏輯集中到協作器之中。
因此，實作此種模式則需要在開發時期及時梳理協作器中的業務邏輯，適時地讓某些不適當的邏輯回歸服務中，避免開發出包含大量額外業務邏輯的協作器。
目前，實作服務協作模式有幾種方向，分別是：
筆者認為在實際的開發場域中，組織微服務的業務邏輯無法預測其複雜性以及需求範圍。DSL 雖然提供了一種簡潔明了的方式來描述服務協作模式，但其主要的缺點在於難以表現複雜的邏輯關係和例外處理。
BPM的圖型化介面對於非技術背景的人來說，提供了一個直觀的方法來組織和管理服務協作。但其主要的挑戰在於當業務流程變得更加複雜時，圖型化的介面可能難以捕捉所有的細節和邏輯關係。
相較於上述兩種方式，程式設計提供了更高的彈性和擴展性。開發者可以使用熟悉的程式語言來描述業務邏輯，也可以利用語言本身的特性來處理複雜的邏輯和例外情況。另外，由於微服務的業務邏輯往往需要與其他系統或服務進行整合，程式設計的方式可以更方便地與其他外部軟體進行溝通。
Anser 服務協作設計理念
在 Anser 的設計中，我們採用了程式設計的方向去實作服務協作模式。將會最大限度地給予開發人員指揮上的自由，依據不同的業務邏輯也能有自訂邏輯判斷的彈性空間。
一個執行期間（Runtime）的協作器由數個 Step 組成，Step 與 Step 之間是具順序性的，必須在上一個 Step 執行完成後下一個 Step 才會開始執行。開發人員可以在 Step 中定義一個或多個 Action，當 Action 的數量大於等於兩個時，協作器便會自動以並行處理的方式與微服務進行連線。當所有 Step 執行完成後，代表協作器執行周期結束。依據不同的重試設定，所有的 Action 都與微服務至少有過一次或以上的存取。
如圖 8 所示，Orchestration 提供兩種可以被使用的類別。
開發者透過繼承 Orchestrator Class 實作出符合自身業務流程的協作器，再透過某個進入點（有可能是某些框架的 Controller 或 Service）建立起協作器實體。透過協作器的幫助與微服務溝通後取得回傳結果。
服務協作設計在當今的微服務架構中因為它概念簡單容易傳達是個熱門的選項，正如我們在本文中所探討的，透過這種模式，開發者可以更有效地集中管理業務邏輯，從而確保流程的清晰和維護性。不只服務協作，Anser 的元件設計重視開發者的靈活性，同時也追求流程的直觀性和明確性。
不過，正如所有技術選擇一樣，服務協作設計也有其挑戰和局限性。當我們選擇使用一個中心化的協作器時，必須確保其不會成為整個系統的瓶頸，並要確保其擴展性和可靠性。另外，也需留意不要過度依賴中心化的協作器，以避免業務邏輯過於集中，從而失去了微服務分散與解耦的初衷。
iThome鐵人賽
看影片追技術